In order to protect information stored in a database, it is known to store sensitive data encrypted in the database. To access the encrypted data, the data must be decrypted, which can only be done by knowing the encryption algorithm and the specific decryption key being used. Access to the decryption keys can be limited to certain users of the database system, and further, different users could be given different access rights.
Specifically, it is preferred to use a so-called granular security solution for the encryption of databases, instead of building walls around servers or hard drives. In such a solution, which is described in WIPO Publication No. WO 97/49211, published on Dec. 24, 1997, a protective layer of encryption is provided around specific sensitive data-items or objects. This prevents outside attacks as well as infiltration from within the server itself. This also allows the system administrator to define which data stored in databases are sensitive and thereby focusing the protection only on the sensitive data, which in turn minimizes the delays or burdens on the system that may occur from other bulk encryption methods.
Most preferably, the encryption is made on such a basic level as in the column level of the databases. Encryption of whole files, tables or databases is not very granular, and thus encrypts both sensitive and non-sensitive data. It is further possible to assign different encryption keys of the same algorithm to different data columns. With multiple keys in place, intruders are prevented from gaining full access to any database since a different key could protect each column of encrypted data.
Such a security solution provides separation of the duties of a security administrator (SA) from a database administrator (DBA). The DBA's role could for example be to perform usual DBA tasks, such as extending tablespaces etc., without being able to see (decrypt) sensitive data. The SA could then administer privileges and permissions, for instance add or delete users.
For most commercial databases, the database administrator has privileges to access the database and perform most functions, such as changing password of the database users, independent of the settings by the system administrator. An administrator with root privileges could also have full access to the database. This is an opening for an attack where the DBA can steal all the protected data without any knowledge of the protection system above if the DBA impersonates another user by manipulating that user's password, even though the user's password is enciphered by a hash algorithm.
An attack could proceed as follows. First the DBA logs in as himself then the DBA reads the hash value of the user's password and stores this separately. Preferably the DBA also copies all other relevant user data. By these actions the DBA has created a snapshot of the user before any altering. Then the DBA executes the command “ALTER USER username IDENTIFIED BY newpassword”. The next step is to log in under the user name “username” with the password “newpassword” in a new session. The DBA then resets the user's password and other relevant user data with the previously stored hash value.
The risk of a DBA attack is further exacerbated by the increased outsourcing of information technology administration. While a company may achieve cost savings by delegating routine management of databases, file systems, etc., a subcontractor is likely trusted less than an internal employee, especially where the subcontractor resides in an unfamiliar legal jurisdiction. Companies recognizing this risk are increasing focused on the separation of duties concept under which system administrators such as DBAs have the ability to perform routine maintenance tasks, while a Security Administrator (SA), often at a high management level, regulates access to sensitive resources. For at least these reasons, it is desirable to provide a system and method of limiting a DBA's ability to access sensitive resources, especially by impersonating a user in an attempt to gain access to the contents of the database.